The discussion of any work, publications, sales, or activity anywhere in this submission, including in any documents submitted with this application, shall not be taken as an admission that any such work constitutes prior art. The discussion of any activity, work, or publication herein is not an admission that such activity, work, or publication existed or was known in any particular jurisdiction.
As software applications become more sophisticated and complex, development of software is often partitioned into different modules. Modules are a collection of subroutines. Programs are partitioned into different subroutines. They require switching between one subroutine and another. The switching from one procedure to another is generally performed by control transfer instructions. In traditional CISC and RISC computers, control transfer can take place with a jump/branch instruction from one position to another of the addressing space. This generates a security issue. If a misbehaving procedure, such as a hacker program or a virus, is intentionally programmed to break into the security system of other programs that share its addressing space, the programs are unprotected and their integrity can be violated. This security hole creates opportunities for hackers and viruses and other malicious code.
Non-Sharing Processes
In current practice, in order to avoid interference, programs are normally executed as processes in different address spaces. By separating address space, different programs are generally invisible to one another. This solution generally provides security by using access control code in translation look aside buffer (TLB) and virtual memory. The solution is practical, but it introduces a large overhead of context switching that can have significant negative impact on performance. In a multiprogramming environment, many processes are running concurrently. The more processes running on the machine, the more overhead in the system due to context switching.
Object-Oriented Virtual System
Currently object-orientated programming (hereafter also referred as OOP) is often used to deal with the protection of subroutines. Object-oriented programming partitions a program into objects. In OOP, an object is a combination of a method (procedure code) and data. Methods are defined within objects as interfaces of communication. A method is an object-oriented version of subroutines. The calling of methods is named method invocation in object-oriented programming. In OOP, communication among objects in generally only performed by method invocation. In contrast with the subroutine calls in non-OOP system, method invocation provides a secure version of control transfer from one domain to the other. Because control transfer is secured in an OOP system, multiprogramming can be achieved by the use of threads instead of processes. In contrast with the process, a thread shares address space with other threads, which means the overhead of context switching between processes can be avoided.
OOP is currently adapted in software applications and operating systems. Though the software is designed with OOP, it still uses control-flow instructions such as jump/branch, which allow the branching from a point to another in the addressing space. These instructions leave security black holes in the level of instruction execution. Current hardware architectures are not designed to run object-oriented programs. The mapping of objects to machine instructions would introduce loss of features in OOP. One employed solution is to provide a virtual system for the running of object oriented (hereafter also referred as “OO”) programs.
Java was introduced as an OOP language. Java programs run on a virtual system, named Java Virtual Machine (JVM). Java programs are translated into machine independent byte-codes before feeding into the JVM for execution. The use of virtual system over a real system (e.g., the underlying processor architecture and operation system, such as wintel) hides the lower layer of machine instructions.
A problem for JVM is its performance. A program running on a virtual system on top of a real system requires two levels of translation, while a program running directly on a real system can directly map program constructs into hardware instructions. The overhead introduced by the virtual system is thus generally a burden for JVM implementations. A program written in C++ that runs directly under Unix, for example, generally always executes faster than the same program written in Java that runs on a JVM.